Nuke was upgraded to 12.8 (supports Swift 6), some of the types are not there anymore

Appearance is a class in SwiftUI and its properties are accessible through InjectedValues.
@injected makes it impossible top make the Appearance itself @MainActor because @Injected(\.images) private var images can't ensure main actor isolation when a type/view X is created.
The other option would be to use a lock within Appearance to make sure everything is concurrency safe, but that feels like too much because the type itself is called from main anyway (if not mistakenly calling from background threads).

also fine to keep it like this, it anyway contains only UI stuff - shouldn't be called from a bg thread

Xcode 15 builds are going away, disabling it for now and a cleanup happens separately

Alternative could be making it @MainActor instead of opting out with nonisolated. But then all out generated L10n structs would need to be MainActor as well which will cause some troubles, since main actor isolation is not available everywhere where L10n is used. Probably fine to keep it unsafe for now.

this is fine

It was giving Sendable related error which did not feel right. Just switched to another sorting method.

DispatchQueue gives Sendable error for self

yes, we should use Task going forward

Since view model factory is MainActor and view models are used from view, then it made more than sense to make all the view models main actor.

Controllers do not ensure on the compilation level which actor is used. We can use any queue for controller completion handlers although the default is main. Therefore, we need to make sure that main is used. Applies to all the completion handlers and controller delegates.

For avoiding actor isolation in the view. Better force main on the view model level.

Promise is not sendable even when making SuggestionInfo sendable, added a unsafe check here for bypassing it.

we should probably refactor this to use async

Making everything getter here avoids making lazy var properties concurrency safe. Note that these are indeed called from different threads.

Otherwise Utils can't init it in-place and adding any MainActor isolation to Utils is not feasible.

UIDevice is main actor whereas UITraitCollection is not

Everything under StreamNuke does not need reviewing since it was Nuke's version upgrade without any manual changes.

It has Any, which can't be Sendable (note that Error is Sendable). Skipping the sendable check here (breaking change to change Any here)

This will give a build warning for SDK users who override it in their view factory. Needs to be highlighted in the CHANGELOG

ouch, that's tricky, can we avoid it?

I'll take it as a TODO to find a way to avoid it.

I went for reverting these changes since these will cause breaking changes for customers. Required some nonisolated(unsafe) handling.

Apple's feedback generator's init is MainActor, therefore it is really difficult to not have our wrapper nonisolated.

Sendable warning if not written out with all the arguments

Many tests want to change main actor isolated types, therefore it is easier to require main actor in a single place

Nuke's LazyImage changes causes it

isn't this causing issues somewhere?

PreferenceKey's protocol requires the default value to be get, therefore this is fine to be defined with let over mutable var (which causes concurrency errors).
Docs

can we avoid this being nonisolated in the LLC?

nonisolated is required because I made the view model @MainActor which I feel like makes sense to have. Controllers have a design where I can set any queue to be the one used for delegate callbacks. In 99% of cases it is the default main queue (highly unlikely that many set their own queues). But because we support any queue for delegate callbacks, we can't make the delegate protocol @MainActor. We can't use @preconcurrency for the delegate conformance because then we would get runtime crash if anyone change the the default queue in the controller to be a background queue.
Ideally we would use our async-await state layer instead of delegates in the future, but that is out of scope.

Summary is that nonisolated can be avoided if view models are not @MainActor (I currenty changed them to be). That said, in the UIKit implementation view controllers are implementing delegates, so nonisolated is required there because UIViewController is @MainActor (similar situation). Similar issue with completion handlers where the calling thread can be any thread.

yes, we should use Task going forward

good to test this part, I remember having crashes on video in the summer (probably it was Xcode bug, but still)

this is fine

this crashes if it's not on the main actor, right? Do we really need that?

It is a custom addition (maybe we should rename it to be more clear about it) which makes sure the closure runs on the main thread. Note that one can set any queue to be the one used for completion handers (default is main). This custom addition just checks if we are currently on the main, if yes, just call the closure, otherwise jump on the main thread (since UI updates and MainActor view models require main).

The difference between:
Task { @MainActor in and MainActor.ensureIsolated is that the latter is quicker.

DispatchQueue.global().async {
            print("Simulate API calls and DB updates")
            DispatchQueue.main.async {
                print(Thread.isMainThread)
                Task { @MainActor in
                    print("Task main actor")
                }
                MainActor.ensureIsolated {
                    print("Ensure isolated")
                }
            }
        }

If this snippet runs, ensure isolated is called first.

I did some micro benchmarking just for fun and the difference is insignificant: we are talking about 1-10 microseconds. Therefore, I guess it makes sense to simplify this and get rid of the custom ensureIsolated.

I renamed the custom addition to StreamConcurrency.onMain. I tried to get rid of it, but loads of unit-tests will break because using a Task introduces slight delay.

we should probably refactor this to use async

why do we change this?

Nuke dropped their image type and gif rendering support in Nuke 12.0 (migration guide). This is their recommendation how to handle gif rendering.

did you take this from Nuke or is it a new implementation?

This I took from SwiftyGif's documentation as a recommended way for rendering gifs in SwiftUI. Not happy that I needed to touch gif rendering, but it is what it is.

ouch, that's tricky, can we avoid it?